Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert Paypal Standard IPN payment_date to system's time zone #13439

Merged
merged 3 commits into from
Jan 16, 2019

Conversation

jgillmanjr
Copy link
Contributor

Overview

Convert payment_date received with the Paypal Standard IPN to the system's time zone

Before

Currently, payment_date is set to (presumably) the local time for Paypal (a Pacific time zone of PST or PDT is part of the timestamp). This leads to the wrong time being written to the database.

After

The timestamp is adjusted to the system's time zone.

Technical Details

Relatively straight forward fix.

Just build a DateTimeZone object for the system's TZ and convert the $receiveDateTime objecting using the setTimezone method.

@civicrm-builder
Copy link

Can one of the admins verify this patch?

@civibot
Copy link

civibot bot commented Jan 12, 2019

(Standard links)

@civibot civibot bot added the master label Jan 12, 2019
@seamuslee001
Copy link
Contributor

Jenkins ok to test

@@ -394,6 +394,8 @@ public function getInput(&$input, &$ids) {
$paymentDate = $this->retrieve('payment_date', 'String', FALSE);
if (!empty($paymentDate)) {
$receiveDateTime = new DateTime($paymentDate);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

won't you have to specify that its in Pacific time on creation or is it doing that sensibly already? Also do we need to do this for PayPalPro IPNs as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is from one of the test IPN messages: payment_date=22:08:43 Jan 11, 2019 PST
But yeah, if the time zone wasn't supplied, this wouldn't work.

Pro does look to require it as well, but the code structure for that was... a bit different:

https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/PayPalProIPN.php#L318

    // CRM-13737 - am not aware of any reason why payment_date would not be set - this if is a belt & braces
    $objects['contribution']->receive_date = !empty($input['payment_date']) ? date('YmdHis', strtotime($input['payment_date'])) : $now;

and https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/PayPalProIPN.php#L534:

$input['payment_date'] = $input['receive_date'] = self::retrieve('payment_date', 'String', 'POST', FALSE);

Since I admittedly don't have a setup for "properly" testing things, and don't have access (and have never used) PayPal pro, I didn't feel comfortable taking a completely dark stab - especially with payment_date being referenced in two locations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -394,6 +394,8 @@ public function getInput(&$input, &$ids) {
$paymentDate = $this->retrieve('payment_date', 'String', FALSE);
if (!empty($paymentDate)) {
$receiveDateTime = new DateTime($paymentDate);
$systemTimeZone = new DateTimeZone(CRM_Core_Config::singleton()->userSystem->getTimeZoneString());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jgillmanjr Can you add a couple of lines of comments into the code here explaining why we need to do the timezone conversion (so anyone looking at this code in the future can work out what is going on and why). Eg. add a sample payment_date as it comes in from paypal etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments in 292785c

@jgillmanjr
Copy link
Contributor Author

Aaanddd apparently pulling in the latest from master killed the build...

@mattwire
Copy link
Contributor

@jgillmanjr You need to do a git "rebase". Something like git rebase -i upstream/master should do it

@jgillmanjr jgillmanjr force-pushed the paypal-standard-ipn-tz-fix branch from 292785c to 6800eef Compare January 14, 2019 19:57
@jgillmanjr
Copy link
Contributor Author

Welp, hopefully that didn't bork things up too bad

@mattwire
Copy link
Contributor

I'm happy with this PR from a technical point of view. @pradpnayak Would you be able to test this?

@pradpnayak
Copy link
Contributor

@mattwire this is incase of subsequent payment callback for recurring?

@seamuslee001
Copy link
Contributor

@pradpnayak no this is just so that the transaction date that is recorded in CiviCRM is when it actually happened in the System's local time not in PayPal's time

@seamuslee001
Copy link
Contributor

Australian Greens have released this to our production environment and the dates are looking correct for us now @mattwire @pradpnayak @eileenmcnaughton are you folks satisfied this is fine to merge?

@seamuslee001
Copy link
Contributor

Jenkins re test this please

@eileenmcnaughton
Copy link
Contributor

@seamuslee001 yes - you have tested it & @mattwire said "I'm happy with this PR from a technical point of view"

@seamuslee001
Copy link
Contributor

Merging based on Matt and I's review

@seamuslee001 seamuslee001 merged commit 1ce4df2 into civicrm:master Jan 16, 2019
@eileenmcnaughton
Copy link
Contributor

@seamuslee001 @jgillmanjr this caused a regression :-( when accessing the ipn through the old path - see https://lab.civicrm.org/dev/drupal/issues/66

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants